The present invention relates to the field of methods and systems for automated decision making.
Disclosed is a system and method for improved modeling of business decision implementation in Customer Care and Billing (CCandB) and Operation Support Systems (OSS). The system and method facilitates the processes whereby a company designs an electronic rating, business or other decision-handling engine of a Billing System or other such system. Currently, the task of designing such an engine is one of the tougher challenges in the construction of a competitive business CCandB and OSS. As the Business Engine is typically the core of a company""s electronic billing system, it needs to be intuitive to use and efficient, scalable and platform independent, yet still able to yield real time outputs in generic form such that it may be applied to a variety of business models. The continuing emergence of next generation communication services and the strong competition between service providers makes new innovative marketing services and rating schemes an everyday event. Thus, there is a need in the art for implementing flexible and generic automation of business decisions for CCandB and OSS.
Prior art systems and methods commonly employed a xe2x80x9cRate Tablexe2x80x9d to model business decisions and a xe2x80x9cRating Engine,xe2x80x9d such as a simple software program, to apply the decisions on a specific event. The Rate Table scheme is currently widely used in many legacy billing systems. A Rate Table is based on the premise that there are few monitored business parameters (usually no more than three), which can be used to select the right xe2x80x9crate,xe2x80x9d generally any value of interest, from the table. This method is typically focused on implementing a rating decision rather then a full business decision, where the rating decision is merely dealing with applying prices or fees (xe2x80x9cratesxe2x80x9d), for a combination of several parameters. The Rating Engine selects the right xe2x80x9crate(s)xe2x80x9d according to the event parameters. FIG. 1 generally depicts an exemplary Rate Table, labeled xe2x80x9cFirst Generation Rate Tablexe2x80x9d. The figure presents an example of a rating decision relating to peak and off-peak (Time of Day) cellular phone airtime fees on one hand, and to Quality of Service (QoS) measurement on the other hand. As seen in the figure, the table is two-dimensional, meaning, it depends on two business parametersxe2x80x94Time of Day and QoS. The combination between Time of Day and QoS parameters determines the desired rate(s). To determine the appropriate airtime rate, one just looks up the corresponding entry in the table for the appropriate Time of Day (Peak or Off Peak) and Quality of Service (QoS1 or QoS2).
There are times when the Rating Engine applies different rates for different segments of the event according to the Rate Table parameters. The order in which the event is segmented may result in different rates for the same Event. An important enhancement of the Rate Table approach can reside in prioritizing the different business parameters. (e.g. QoS has higher priority than Time of Day, thus the Event will be segmented first according to QoS and only then each segment will be divided by Time of Day).
The advantage of the Rate Table method is its simplicity and ease of use in representing non-complex business decisions, or more specifically rating decisions. By all respects, for one or two dimensions, it is equally simple to visually present a Rate Table to the, end user of the system and to design a Rating Engine to support it. Unfortunately, a Rate Table has fixed business parameters with a fixed number of dimensions that often makes it difficult to define a rating method based on new parameter without the painful customization involving re-coding part of the billing system. These drawbacks make it merely suitable for certain application types that are relatively simple in nature.
To address the problems inherent in the Rate Table, the prior art has developed a variation of the Rate Table that expands the table to greater power and flexibility. The new concept is that of a multi-dimensional or n-dimensional Rate Table. An example of such a method is represented in FIG. 1 labeled as a xe2x80x9cSecond Generation Multi-Dimensional Rate Tablexe2x80x9d. Due to the fact that it is extremely difficult to visually represent more than two dimensions in a table, the multi-dimensional Rate Table uses a set of rules to decide the right action. Each rule represents a single combination of the of 1 or more of the xe2x80x98nxe2x80x99 parameters. These series of rules dictate actions to be taken whenever certain relationships exist between any number of business parameters (xe2x80x9cdimensionsxe2x80x9d) from a predetermined list of business parameters.
While the use of a second generation multi-dimensional Rate Table creates more flexibility and power than first generation Rate Tables, this method creates new drawbacks. The most profound one is the lack of ability to visually depict an n-dimensional table when xe2x80x9cnxe2x80x9d, the number of dimensions or parameters, grows large. While it may be solved by converting a table-cell (or group of cells) in a multi-dimensional table into a rule, this makes the implementation of a rating decision exceedingly difficult. Furthermore, logically converting business decisions into such a table of rules is not intuitive and it is ultimately difficult to tell whether all rating options are covered. Moreover, the major drawback of the Rate Table remainsxe2x80x94both methods are particularly useful in implementing only a rating decision (economic) as opposed to business decision. In other words, business decisions that result in more than purely economic outcomes can not be presented in those methods. Some such potential uses for CCandB or OSS engines include: bonuses (monetary or not), discounts, loyalty credits, provisioning of external devices and activation or de-activation of services. In most cases this drawback leads to complex solution of those business decisions, outside the scope of the Rate Table.
Thus, there remains a need in the art for an improved decision system and method and in particular for use in CCandB and OSS, that overcomes the above-described and other disadvantages inherent in the prior art.
The quest for new techniques for a generic business decision model and engine has led to the system and method of the present invention which utilizes a Decision Operation Tree, or a DO Tree(trademark). This third generation approach not only solves the above discussed and other disadvantages of the prior art, but also allows the integration of various decision making rules into one system. In embodiments of the present invention, the DO Tree is advantageous over Rate Tables and multi-dimensional rate tables in that it facilitates the application of decision engines into a variety of areas which, prior to the present invention, were usually considered to lie outside the scope of Rate Table methodologies.
A DO Tree according to the present invention is a logical tree representation, comprised of Nodes and Branches, of decision making rules and actions instituted according to those rules. In preferred embodiments of the invention, one or more DO Trees are tailored to serve a user""s rating and billing system needs. Methods according to the present invention include representing a series of decisions necessitated by the occurrence of a predefined event with a DO Tree as herein described. Upon occurrence of the predefined event, the method includes proceeding from Node to Node, and optionally performing one or more actions in each Node, in the DO Tree according to the rules the DO Tree provides.
Systems according to the present invention include a storage media, a processor, and software run by the processor. One or more DO Trees according to the present invention are stored-on the storage media. Upon the occurrence of a predefined event, the software of the system performs the decisions and actions dictated by, one or more of the stored DO Trees. The present invention, however, is not dependent on any particular storage media, processor or other hardware.
According to the present invention, Do Trees are comprised of a plurality of Nodes and Branches which connect the nodes together in a progressive relationship. Any node may have defined for it one or more xe2x80x9cActionsxe2x80x9d (whose implementation can be prioritized or ordered) which are triggered whenever the Node is reached. Those Nodes having Branches stemming (xe2x80x9cdescendingxe2x80x9d) from them have two parameters, a Decision Attribute and a Branching Type, which defines the Node""s relationship with its descending Branches. Conversely, each Branch is defined by a parameter called a Decision Value. For each Node having descending Branches, the specified Decision Attribute defines what type of attribute the Node""s branches""s Decision Value parameters are referring to. Thus, the interaction of these two paramters determine what branch or branches should be followed to the next Node. Additionally, each Node having Branches has specified a Branching Type parameter. The Branching Type parameter also helps chose which Branches are followed in the DO Tree. This parameter can have various values, including: Step, Tier, and Period. Each one of these branching types dictate different splitting actions when the DO tree is evaluated for a specific event.
The constituent components of DO Trees and systems and methods according to the present invention will be discussed in more detail below with respect to the drawings and description of several embodiments of the present invention. It should be understood that the forthcoming description is merely illustrative and is by no means limitative of the invention as claimed.